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Abstract 



We define a simple collection of operations for creating and manipulating record 
structures, where records are intended as finite associations of values to labels. A 
second-order type system over these operations supports both subtyping and 
polymorphism. We provide typechecking algorithms and limited semantic models. 

Our approach unifies and extends previous notions of records, bounded 
quantification, record extension, and parametrization by row-variables. The general aim 
is to provide foundations for concepts found in object-oriented languages, within a 
framework based on typed lambda-calculus. 



Appears in: Mathematical Structures in Computer Science, vol 1, pp. 3-48, 1991 

SRC Research Report 48, August 25, 1989. Revised January 1, 1993. 
© Digital Equipment Corporation 1989,1993. 

This work may not be copied or reproduced in whole or in part for any commercial purpose. Permission to copy in whole or in part 
without payment of fee is granted for nonprofit educational and research purposes provided that all such whole or partial copies 
include the following: a notice that such copying is by permission of the Systems Research Center of Digital Equipment Corporation 
in Palo Alto, California; an acknowledgment of the authors and individuals contributors to the work; and all applicable portions of the 
copyright notice. Copying, reproducing, or republishing for any other purpose shall require a license with payment of fee to the 
Systems Research Center. All rights reserved. 



Page 1 



1. Introduction 

Object-oriented programming is based on record structures (called objects) intended 
as named collections of values {attributes) and functions {methods). Collections of 
objects form classes. A subclass relation is defined on classes with the intention that 
methods work "appropriately" on all members belonging to the subclasses of a given 
class. This property is important in software engineering because it permits after-the-fact 
extensions of systems by subclasses, without requiring modifications to the systems 
themselves. 

The first object-oriented language, Simula67, and most of the more recent ones (see 
references) are typed by using simple extensions of the type rules for Pascal-like 
languages. These extensions mainly involve a notion of subtyping. In addition to 
subtyping, we are interested here in more powerful type systems that smoothly 
incorporate parametric polymorphism. 

Type systems for record structures have recently received much attention. They 
provide foundations for typing in object-oriented languages, data base languages, and 
their extensions. In [Cardelli 88] the basic notions of record types, as intended here, were 
defined in the context of a first-order type system for fixed- size records. Then Wand 
[Wand 87] introduced the concept of row-variables while trying to solve the type inference 
problem for records; this led to a system with extensible records and limited second-order 
typing. His system was later refined and shown to have principal types in [Jategaonkar 
Mitchell 88], [Remy 89], and again in [Wand 89]. The resulting system provides a flexible 
integration of record types and Milner-style type inference [Milner 78]. 

IVIeanwhile [Cardelli Wegner 85] defined a full second-order extension of the system 
with fixed-size records, based on techniques from [Mitchell 84]. In that system, a program 
can work polymorphically over all the subtypes 5 of a given record type A, and it can 
preserve the "unknown" fields (the ones in B but not in A) of record parameters from 
input to output. However, some natural functions are not expressible. For example, by the 
nature of fixed- size records there is no way to add a field to a record and preserve all its 
unknown fields. Less obviously, a function that updates a record field, in the purely 
applicative sense of making a modified copy of it, is forced to remove all the unknown 
fields from the result. Imperative update also requires a careful typing analysis. 

In this paper we describe a second-order type system that incorporates extensible 
records and solves the problem of expressing the natural functions mentioned above. We 
believe this second-order approach makes the presentation of record types more natural. 
The general idea is to extend a standard second-order (or even higher-order) type system 
with a notion of subtyping at all types. Record types are then introduced as specialized 
type constructions with some specialized subtyping rules. These new constructions 
interact well with the rest of the system. For example, row-variables fall out naturally 
from second-order type variables, and contravariance of function spaces and universal 
quantifiers mixes well with record subtyping. 
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In moving to second-order typing we give up the principal type property of weaker 
type systems, in exchange for some additional expressiveness. But most importantly for 

us, we gain some perspective on the space of possible operations on records and record 
types, unencumbered (at least temporarily) by questions about type inference. Since it is 
not clear yet where the bounds of expressiveness may lie, this perspective should prove 
useful for comparisons and further understanding. 

The first part of the paper is informal and introduces the main concepts and problems 
by means of examples. Then we formalize our intuitions by a collection of type rules. We 
give a normalization procedure for record types, and we show soundness of the rules with 
respect to a simple semantics for the pure calculus of records. Finally, we discuss 
applications and extensions of the basic calculus. 

2. Informal development 

Before looking at a formal system, we describe informally the desired operations on 
records and we justify the rules that are expected to hold. The final formal system is 
rather subtle, so these explanations should be useful in understanding it. 

We also give simple examples of how records and their operations can be used in the 
context of object-oriented languages. 

2.1 Record values 

A record value is intended to represent, in some intuitive semantic sense, a finite map 
from labels to values where the values may belong to different types. Syntactically, a 
record value is a collection of fields, where each field is a labeled value. To capture the 
notion of a map, the labels in a given record must be distinct. Hence the labels can be 
used to identify the fields, and the fields can be taken to be unordered. This is the notation 
we use: 

0 the empty record. 

{x=3, y=true) a record with two fields, labeled x and y, 

equivalent to {y^true, x^3). 

There are three basic operations on record values. 

• Extension {r\x=a) ; adds a field of label x and value a to a record r, provided a field of 
label X is not already present. (This condition will be enforced statically.) We write 
{r\x-a\y=b) for {{r\x-a)\y=b) . 

• Restriction r\x ; removes the field of label x, if any, from the record r. We write Axy 
for r\x\y. 

• Extraction r.x ; extracts the value corresponding to the label x from the record r, 
provided a field having that label is present. (This condition will be enforced statically.) 
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We have chosen these three operations because they seem to be the fundamental 

constituents of more complex operations. An alternative, considered in [Wand 87], would 
be to replace extension and restriction by a single operation that either modifies or adds a 
field of label x, depending on whether another field of label x is already present. In our 
system, the extension operation is not required to check whether a new field is already 
present in a record: its absence is guaranteed statically. The restriction operation has the 
task of removing unwanted fields and fulfilling that guarantee. This separation of tasks 
has advantages for efficiency, and for static error detection since fields cannot be 
overwritten unintentionally by extension alone. Based on a comparison between the 
systems of [Wand 87J and [Jategaonkar Mitchell 88], it also seems possible that a reasonable 
fragment of our language will have a practical type inference algorithm. 

Here are some simple examples. The symbol ^ (value equivalence) means that two 



expressions denote the same value. 



{{)\x=3) 
{{x=3)\y=true) 
{x=3, y=true)\y 
{x=3, y=true)\z 
{x=3, y=true)jc 

{{x^3)\x=4) 
{x=3).y 



^ {x=3) 

^ {x=3, y=true) 

^ {x^3) 

(x=5, y=true) 
^ 3 

invalid extension 
invalid extraction 



extension 

restriction (cancelling _y) 
(no effect) 

extraction 



Some useful derived operators can be defined in terms of the ones above. 

• Renaming r\x'^y\ =^^^ {r\x\y^r.x): changes the name of a record field. 

• Overriding (r x=a) =^^^ {r\x\x=a): if x is present in r, overriding replaces its value 
with one of a possibly unrelated type, otherwise extends r (compare with [Wand 89]). 
Given adequate type restrictions, this can be seen as an updating operator, or a method 
overriding operator. We write (r ;c=a y^) for ((r x^a) y=b). 

Obviously, all records can be constructed from the empty record using extension 
operations. In fact, in the formal presentation of the calculus, we regard the syntax for a 
record of many fields as an abbreviation for iterated extensions of the empty record, e.g.: 



{x=3) 

{x=3, y=true) 



'def 
'def 



{{)\x=3) 

{{{)\x=3)\y=true) 



This definition allows us to express the fundamental properties of records in terms of 
combinations of simple operators of fixed arity, as opposed to n-ary operators. Hence, we 
never have to use schemas with ellipses, such as {xj-aj , x^-a^), in our formal 
treatment. 

Since r\x r whenever r lacks a field of label x, we can formulate the definition 
above using any of the following expressions: 
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{{)\x=3\y=true) ^ {{0\x\x=3)\y\y=true) ^ {{) x=3 y=true) 

The latter forms match better a similar definition for record types, given in the next 
section. 



2.2 Record types 

In describing operations on record values we made positive assumptions of the form 
"a field of label x must occur in record r" and negative assumptions of the form "a field of 
label X must not occur in record r". 

These constraints will be verified statically by embedding them in a type system, 
hence record types will convey both positive and negative information. Positive 
information describes the fields that members of a record type must have. (Members may 
have additional fields.) Negative information describes the fields the members of that 
type must not have. (Members may lack additional fields.) 

Note that both positive and negative information expresses constraints, hence 
increasing either kind of information will lead to smaller sets of values. The smallest 
amount of information is expressed by the record type with no fields, O, which therefore 
denotes the collection of all records, since all records have at least no fields and lack at 
least no fields. This type is called the total record type. 

O the type of all records. 

Contains, e.g.: 0, {x=3). 

Q\x the type of all records which lack fields of 

label X. E.g.: (), {y=true), but not U=5). 

ix:Int, y:Boo§ the type of all records which have at least fields 

of labels x and y, with values of types Int and 
Bool. E.g.: {x=3, y=true), {x=3, y=true, z-"str"), 
but not (x=i, y=4), {x=3). 

ix.IntlAy the type of all records which have at least a field 

of label X and type Int, and no field of label y. 
E.g. {x=3, z="str"), but not {x=3, y=true). 

Hence a record type is characterized by a finite collection of (positive) type fields (i.e. 
labeled types) and negative type fields (i.e. labels)!, -^^e often simply say "fields" for 
"type fields". The positive fields must have distinct labels and are unordered. Negative 
fields are also unordered. We have assumed so far that types are normalized so that 
positive and negative labels are distinct, otherwise positive and negative fields may 
cancel, as described shortly. 



In this section we consider only ground tecord types, i.e., those containing no record type variables. 
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As with record values, we have three basic operations on record types. 

• Extension iR\x:A]) : This type denotes the collection obtained from R by adding x fields 
with values in A in all possible ways (provided that none of the elements of R has x 
fields). More precisely, this is the collection of those records {r\x=a) such that r is in i? 
and a is in A, provided that a positive type field x is not already present in R. (This 
condition will be enforced statically.) We sometimes write ^R\x:A\y:B} for i^R\xA}\y:B}. 

• Restriction R\x : this type denotes the collection obtained from R by removing the field 
X (if any) from all its elements. More precisely, this is the collection of those records r\x 
such that r is in R. We write R\xy for R\x\y. 

• Extraction R.x : this type denotes the type associated with label x in R, provided R has 
such a positive field. (This condition will be enforced statically.) 

Again, derived operators can be defined in terms of the ones above. 

• Renaming R[x'^y] =^^^ iR\x\y=R.xl): changes the name of a record type field. 

• Overriding iR^xAl) =^^^ iR\x\x.Al): if a type field x is present in R, overriding 
replaces it with a field x of type A, otherwise extends R. Given adequate type restrictions, 
this can be used to override a method type in a class signature (i.e. record type) with a 
more specialized one, to produce a subclass signature. 

The crucial formal difference between these operators on types and the similar ones 
on values is that type restrictions do not cancel as easily, for example: 0\j ^ O, ^xAl)\y 
^ ixAl), etc., since 0\y is a smaller set than O. As a consequence, one must always make 
a type restriction before making a type extension, as can be seen in the examples below, 
because the extension operator needs proof that the extension label is missing. The 
symbol ^ (type equivalence) means also that two type expressions denote the same type. 



\x\x:Intl) 
Ux:Intl)\y\y:Boot^) 
ix:Int, y:Boofi)\y 
ix'.Int, y:Booti)\z 
ix.Int, y.Booth.x 



)\x:Intl} 
ix:Int]}\x:Intl) 
ix.Intl).y 



ix-.Intll 

ix:Int, y.Booth 
ix:Intlj\y 
ix:Int, y:Bool^\z 
Int 

invalid extension 
invalid extension 
invalid extraction 



extension 

restriction (cancelling j) 

(no effect onx,y) 

extraction 



It helps to read these examples in terms of the collections they represent. For 
example, the first example for restriction says that if we take the collection of records that 
have X and y (and possibly more) fields, and remove the y field from all the elements in 
the collection, then we obtain the collection of records that have an x field (and possibly 
more fields) but no y field. In particular, we do not obtain the collection of records that 
have X and possibly more fields, because those would include y. 
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The way positive and negative information is formally manipulated is easier to 
understand if we regard record types as abbreviations, as we did for record values, e.g.: 

bc:Intli m\x\x:Intl) 

ix:Int, y:BooB =^^^ im\x\x.Inmy\y:Boollf 

Then, when considering iy:Bootii\y we actually have the expansion iilj\y\y:Boorii\y. If we 
allow the outside positive and negative y labels to cancel, we are still left with 0\y. In 
other words, the inner y restriction reminds us that y fields have been eliminated. 

Remark. It is deceptive to think that every record in iR\x.Al) has at least the fields 
of some record in R (i.e., that iR\x-Al) has "more type fields" than R), since 
iR\x:Al) is not necessarily contained in R. For example, if R=il)\x the two 
collections are incomparable. 

Based on this example, one might then think that iR\x\x\Al] has more type 
fields than R, and this is indeed true fori?=0. However, in general this fails; for 
example i?=0\x makes the collections incomparable, and i?=^0\xlx:A^ causes the 
two collections to have the same fields. 

It is also deceptive to think that R\x has fewer type fields than R, since R is in 
general not contained in R\x. This containment is true for R=Q\x, but false for 
R=0 where the opposite is true, and R-iO\x\xAl) makes the two collections 
incomparable. 

These observations might appear to conflict with our previous assertion that 
positive and negative information always makes things smaller. The assertion is 
true for normalized record types, but not for arbitrary applications of operators 
which may later cancel out. We shall study the normalization process in a later 
section. 



2.3 Record value variables 

Now that we have a first understanding of record types, we can introduce record value 
variables which are declared to have some record type. For example, r-M\y means that r 
must not have a field y, and r. h:Al) means that r must have a field x of type A. The well- 
formed record expressions can now be formulated more precisely: 

{r\x=a) where r:Q\x 

Ax where r.Q 

r.x where r:^x:AMor some A 

Record value variables can now be used to write function abstractions. Here we have 
a function that increments a field of a record, and adds another field to it: 

letfir: ix:Intl)\y) : bc:Int,y:Intl) = 
{r «- x=r.x+l \y=0) 
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This function requires an argument with a field x and no field _y; it has type: 

/: ix:Int}\y ix:Int, yJntli 

and can be used as follows: 

j{{x^3)) (jc=4, y^O) : ix:Int, y:Intl) 

f[,{x=3, z=true)) {x^4, y=0, z=true) : ix:Int, yJntll 

The first application uses the non-trivial fact that {x=3) : bi:Intli\y. We could also have 
matched the parameter type precisely by /((jc=5)\y), which is of course equivalent. The 
second application is noticeable for several reasons. First, it uses the non-trivial fact that 
{x=3, z=true) : ix:Intli\y. Second, the "extra" field z is preserved in the result value, 
because of the way /is defined. Third, the "extra" field z is not preserved in the result 
type, because /has a fixed result type; we shall come back to this problem. 

Remark. An alternative syntactic notation, along the lines of [Jategaonkar Mitchell 
88], could use pattern matching of record parameters: 

let j{{rAy\x=rx)) : ix:Int,y:Intll = 
{rr\x=rx+l\y=0) 

Here the actual parameter must match the shape of a record with a field x and a 
collection of remaining components that lack y. The variables rr and rx are bound 
to the appropriate components and then used in the body of / where rr acquires 
the assumption that it does not contain either x or y fields. There are some non- 
trivial details to pattern matching in the presence of subtyping. Since our main 
objective is to illustrate the fundamental ideas, we choose the simpler syntax. 

2.4 Record type variables 

In the previous section we introduced record value variables, and we used record 
types to impose restrictions on the values which could be bound to such variables. Now 
we want to introduce record type variables in order to write programs that are 
polymorphic over a collection of record types. We similarly need to express restrictions 
on the admissible types that these variables can be bound to; these restrictions are written 
as subtype specifications. 

To write subtype specifications, we use a predicate A<:B meaning that A is a subtype 
of B: in other words, every value of A is also a value of B. The typing rule based on this 
condition is called subsumption, and will play a central role in the formal system. 

Using subtype assumptions, we can better formulate the restrictions on the record type 
operators: 
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m\x:Al) where R <: Q\x 

R\x where R <: O 

R.X where R <: ix:A]) for some A 

We may now write a polymorphic version of the function/of the previous section: 

letJ{R<:(lx:Intl)\y)(r:R) : m\y:Intl) = 
{r x=r.x+l \y=0) 

This function expects first a type parameter R which must be a subtype of ix:Intl)\y, and 
then an actual value parameter of type R. An example application is: 

j{bc\Int, z:Booll)\y)({x^3, z=true)) ^ 

{x=4, y=0, z=true) : ix.Int, y.Int, z'.Booll) 

First, note that R is bound to ir.Int, z'-Boollhy, which is a subtype of ix:Int}\y as required. 
Second, {x^3, z-true) has type ix'.Int, z:Booll)\y as required. Third, the result type, 
obtained by instantiating R, is ihcJnt, z:Booll)\y\y:Intl), which is the same as ix:Int,y:Int, 
z:Booll) by definition. Finally, note that the "extra" field z has not been forgotten in the 
result type this time, because all the "extra" fields are carried over from input to output 
type by the type variable R. This is the advantage of writing/in polymorphic style. 

What is the type of /then? We cannot write this type with simple function arrows, 
because we have a free variable R to bind. Moreover, we want to mark the precise 
location where this binding occurs, because this permits more types to be expressed. 
Hence, we use an explicit bounded universal quantifier. 

f: \/(R<-Ax:Intl)\y) R m\y:Intl) 

This reads rather naturally: "for all types R which are subtypes of ix:Int}\y,f is a function 
fromi? to ^R\y:IntT\ (The scope of a quantifier extends to the right as much as possible.) 

Remark. Notice that we have freedom in the typing of the polymorphic function 
/, for example, we could have chosen the typing: 

letJ{R<:Q\xy)(r.mx:Intl)) : iR\x:Int\y:Intl} = 
(r «- x=r.x+l \y=0) 

j{iz'.BoollAxy)(bc=3, z=true)) : ix.Int, y:Int, zBooth 

This typing turns out to be incomparable with the previous one; in general we do 
not seem to have a "best" way of typing an expression. However, we have not 
studied this aspect of the system carefully. 
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2.5 Subtype hierarchies 

Our operations on record types and record values make it easy to define new types 
and values by reusing previously defined types and values. 

For example, we want to express the subtype hierarchy shown in the diagram below, 
where various entities can have a combination of coordinates x and y, radius r, and color 
c. 

First, we could define each type independently: 

let Point = hc'.Real, y.Real} 

let ColorPoint = ix.Real, y:Real, c.Color} 

let Disc = ix:Real, y.Real, r.Reall} 

let ColorDisc = ix.Real, y.Real, r.Real, c: Color} 

But these explicit definitions do not scale up easily to large hierarchies; it is much 
more convenient to define each type in terms of previous ones, e.g: 

let Point = ix.Real, y.Real} 

let ColorPoint - iPoint c: Color} 

let Disc = iPoint <- r.Reall) 

let ColorDisc = iColorPoint r:Real} 

Note that iPoint\c: Color} would not be well-formed here, since members of Point may 
have a c label. In section 4.3 we shall examine another way of defining this hierarchy, for 
example deriving Point from ColorPoint by "retracting" the c field. 

Point 
xy 

/ \ 

ColorPoint Disc 
xy c xy r 

\ / 

ColorDisc 
xy r c 

Similarly, record values can be defined by reusing available values: 

let p'.Point = {x=3, y=4) 
let cp: ColorPoint = (p <- c=green) 
let cd: ColorDisc = {cp*- r=l) 
let d:Disc = cd\c 

We should notice here that the subtyping relation depends only on the structure of the 
types, and not on how the types are named or constructed. Similarly, record values belong 
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to record types uniquely based on their structure, independently of how they are declared 
or constructed. 

Another observation, which we already made in a more abstract context, is that 
PoinAr <: Point since Point does not contain r, but Poinhy is incomparable with Point 
since Point requires yJnt while Point\y forbids it. 

2.6 The update problem 

The type system for records we have described in the previous sections was initially 
motivated by a single example which involves typing an update function. Here updating 
is intended in the functional sense of creating a copy of a record with a modified field, but 
the discussion is also relevant to imperative updating. 

The problem is to define a function that updates a field of a record and returns the 
new record; the type of this function should be such that when an argument of the 
function has a subtype of the expected input type, the result has a related subtype. That is, 
no type information regarding additional fields should be lost in updating. (We have 
already seen that bounded quantification can be useful in this respect.) 

It is pretty clear what the body of such a function should look like; for example for an 
input r and a boolean field b which has to be negated, we would write: 

(r «- b=not{r.b)) (an abbreviation for {Ab\b=not{r.b)) ) 

The overriding operator here preserves the additional fields of r. 

One might expect the following typing, which seems to preserve subtype information 
as desired: 

let update{R<:ib:Bootf)){r:R): R = 
(r <- b=not(r.b)) 

In words, we expect update to be a function from R to R, for any subtype R of ib:Booll). 
But this typing is not derivable from our rules and, worse, it is semantically unsound. To 
see this, assume we have a type True <: Bool with unique element true, as follows^: 

true : True <: Bool 

not : Bool -» Bool (alternatively, not : \/(A<:Bool)A-^Bool) 

update{ib:Trueli){{b=true)) ^ {b=false) : ib:Truell 

This use of update produces an obviously incorrect result type. In general, a function with 
result type R has a fixed range; it cannot restrict its output to an arbitrary subtype of R, 
even when this subtype is given as a parameter. 



^Although the singleton type True may seem artificial, this argument can be reformulated with any proper inclusion between 
two types. 
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To avoid this problem, we must update the result type as well as the result. The 

correct typing comes naturally from typechecking the body of update according to the 
rules for each construct involved; note how the shape of the result type matches the shape 
of the body of the function: 

let update (R<:(lb:BooB)(r.Ry. iR^b:Boolli = 
(r b=not(r.b)) 

update (ib:Truel))({b=true)) ^ 

{b=false) : {iib:Trueli^b:Bootii ^ ib:Bool}) 

The outcome is that the overriding operator on types, which involves manipulation of 
negative information, is necessary to express the type of update functions. Bounded 
quantification by itself is not sufficient. 

The type V(5<:A) B B turns out to contain only the identity function on A in many 
natural semantic models, such as [Bruce Longo 88]. For example take A=Int and let the 
subranges [n..m] be subtypes of Int. Then any function of type \/(B<:Int) B ^ B can be 
instantiated to [n..n\ -» [n..n], hence it must be the identity on [n..n] for any n, and hence 
the identity over all of Int. 

A further complication manifests itself when updating acts deep in a structure, 
because then we have to preserve type information with subtyping occurring at multiple 
levels. Here is the body of a function that negates the s.a.b field of a record s of type 

ia:ib:Boom : 

(5"«-a=(s. a<-b=not(s. a.b))) 

The following is a correct typing which does not lose information on subtypes (simpler 
typings would). Here we need to introduce an additional type parameter in order to use 
two type variables in the result type and to avoid two possible ways of losing type 
information: 

letdeepUpdate{R<:ib:Booth){S<:ia:Rl)){s:S): iS^aM^kBooM = 
{s*-a={s. a*-b=not(s. a.b))) 

Of course this is rather clumsy; we need one additional type parameter for each additional 
depth level of updating. Fortunately, we can avoid the extra type parameters by using 
extraction types S.a. Again, the following typing comes naturally from typechecking the 
body of deepUpdate according to the rules for each construct: 

let deepUpdate{S<:ia:ib:Boom){s:S): iS^a-.iS.a^kBooM = 
{s*-a={s. a'^b=not(s. a.b))) 

The output type is still complex (it could be inferred) but the input is more natural. Here 
is a use of this function: 
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deepUpdate{ia:ih\True , c.Cl), d:Dl!)({a-{b-true, c-v), d-w)) ^ 
{a={b=false, c=v), d=w) : ia:ib:Bool, cCh, d:Dl) 



Here we have provided an argument type that is a subtype of ia:ib:Booll)l) in "all possible 
ways". 

Finally, we should remark that the complexity of the update problem seems to 
manifests itself only in the functional case, while simpler solutions are available in the 
imperative case. Simpler type systems for records, such as the one in [Cardelli Wegner 85J, 
may be adequate for imperative languages when properly extended with imperative 
constructs, as sketched below. 

The imperative updating operator := has the additional constraint that the new record 
should have the same type as the old record, since intuitively updating is done "in place". 
This requirement produces something very similar to the typing we have initially shown 
to be unsound. Here assignable fields are identified by van 

let update (RK-Avar b:Boofi)){r.R): R = 
r.b := not(r.b) 

Soundness is then recovered by requiring that assignable fields be both covariant and 
contravariant. Hence, True <: Bool does not imply ivar b:Truel] <: ivar b:Booll), thereby 
blocking the counterexamples to soundness. 

Imperative update, with the natural requirement of not changing the type of a record, 
leads to simpler typing. However, this approach does not completely solve the problem 
we have discussed in this section. Imperative update alone does not provide the 
functionality of polymorphically extending existing records; when this is added, all the 
problems discussed above about functional update resurface. 

3. Formal development 

Now that we have acquired some intuitions, we can discuss the formal type inference 
rules in detail. We first define judgment forms and environment structures. Then we look 
at inference rules individually, and we analyze their properties. Finally, we provide a set- 
theoretical semantics for the pure calculus of records. 

3.1 Judgments and inferences 

A judgment is an inductively defined predicate between environments, value terms, 
and type terms. The following judgments are used in formalizing our system: 

h E env E is an environment 

E\- A type A is a type 

E\- A<:B A is a subtype of B 

Page 13 



E\- a: A 



a has type A 



E\- A B equivalent types 

E\- a*^ b -.A equivalent values of type A 

The formal system is given by a set of inference rules below, each expressed as a 
finite set of antecedent judgments and side conditions (above a horizontal line) and a 
single conclusion judgment (below the line). Most inference rules are actually rule 
schemas, where meta- variables must be instantiated to obtain concrete inferences. For 
typographical reasons, we write the side conditions for these schemas as part of the 
antecedent. 

3.2 Environments 

An environment £ is a finite sequence of (a) unconstrained type variables, (b) type 
variables constrained to be subtypes of a given type, and (c) value variables associated 
with their type. 

We use dom(E) for the set of type and value variables defined in an environment. 

(ENVl) (ENV2) (ENV3) (ENV4) 

X^dom(E) E\- A type X^dom(E) E\- A type x^dom(E) 
h 0 env \- E,X env h E, X<:A env h E, x\A env 

Hence, a legal environment is obtained by starting with the empty environment 0 and 
extending it with a finite set of assumptions for type and value variables. Note that the 

assumptions involve distinct variables; we could perhaps allow multiple assumptions 
(e.g., 0, X<:A, X<:B) but this would push us into the more general discipline of 

conjunctive types. 

Assumptions about variables can then be extracted from well-formed environments: 

(VARl) (VAR2) (VAR3) {VAR4) 

h E,X,E' env h E,X<:A,E' env h E,X<:A,E' env \- E,x-A,E' env 

E,X,E'\-Xtype E,X<:A,E' \- X type E,X<:A,E' \- X<A E,x:A,E' \- x:A 

All legal inferences take place in (well-formed) environments. All judgments are 
recursively defined in terms of other judgments. For example, above we have used the 
typing judgment E\- A type in constructing environments; vice versa, well-formed 
environments are involved in constructing types. 

We now consider the remaining judgments in turn. 

3.3 Record type formation 

The following collection of rules determines when record types are well-formed. 
There is some interdependence between this section and the following ones, since 
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equivalence rules have assumption that involve subtyping, which is discussed later. 
Fortunately, these assumptions are fairly simple, so a full understanding of the subtype 
relation is not required at this point. 

(Fl) (F2) (F3) (F4) 

hEenv E\-R<:Q\x Eh A type E\-R<:Q E \- R<-AS\x-Al!<:Q 

Eh ill type Eh iR\x.Al) type EhR\xtype EhR.xtype 

As shown above, and already discussed informally, the legal record types are: the type 
of all records, O; a record type variable X, (because of (var2) in the previous section); an 
extension iR\r.Al) of a record type 7?, provided R does not have x; and a restriction R\x 
of a record type R. Moreover, extracting a component R.x of a record type R that has a 
label x, produces a legal type. 

In general, if R does not have x, then R will be a subtype of the type Q\x of all records 
without X. This explains the hypothesis of rule (F2). In rule (F4) we use R<:iS\x-Al) to 
guarantee that every record in R has an x field. 



3.4 Record type equivalence 

When are two record types equivalent? We discuss here the formal rules for 
answering such a question. Type equivalence, as a relation, is reflexive (over well-formed 
expressions), symmetric, and transitive; it is denoted by the symbol Substituting two 
equivalent types in a third type should produce an equivalent result; this is called the 
congruence property, and requires a number of rules to be fully formalized (these are 
listed in section 3.7). We now consider, by cases, the equivalence of extended, restricted 
and extracted record types. 

Two extended record types are equivalent if we can reorder their fields to make them 
identical (or, recursively, equivalent). This simple fact is expressed by the following rule. 
A number of applications of this rule, and of the congruence property, may be necessary 
to adequately reorder the fields of a record type. 

(TEl) 

E\-R<:Q\xy E \- A,B type xi=y 
E h imx-Alt\ym ^ iWyMh-Al) 

Similarly, we can reorder restrictions. Moreover, a double restriction R\xx reduces to R\x. 
This fact is expressed in slightly more general form below, since the assumption that R 
does not have x is sufficient to deduce that R\x is the same asR : 

(TE2) (TE3) 

E\-R<:Q\x E\-R<:Q 
E\-R\x^R E\- R\xy ^ R\yx 
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The most interesting rules concern the distribution of restriction over extension. An 
outside restriction and inner extension of the same variable can cancel each other. 
Otherwise, a restriction can be pushed inside or outside of an extension of a different 
variable. 

(TE5) (TE6) 

E\-R<-M\x Eh A type E h i?<:OU Eh A type x^y 

E h iR\x:Ali\x Eh iRh-.A'iXy ^ iR\y\xAl) 

Note however that in a situation like iR\x\x.Al) no cancellation or swap can occur. The 
inner restriction may be needed to guarantee that the extension is sensible, and so neither 
is redundant. 

Finally, a record extraction is equivalent to the extracted type: 

(TE7) (TE8) 

EhR<:ili\x Eh A type E h R<-AS\yM\x<-M Eh A type x^y 

EhiR \x.Alx ^ A EhiR \x.Aly ^ R.y 

(TE4) 

EhR<-AS\yM<-il) x^y 
E h R\x.y ^ R.y 

These equivalence rules can be given a direction and interpreted as rewrite rules 
producing a normal form for record types; normalization is investigated in a later section. 



3.5 Record subtyping 

We have seen that subtyping is central to the notion of abstracting over record type 
variables, and we have intuitively justified some of the valid subtype assertions. In this 
section we take a more rigorous look at the subtype relation. 

Subtyping should at least be a pre-order: a reflexive and transitive relation. Given a 
substitutive type equivalence relation such as the one discussed in the previous 
section, we require: 

(Gl) (G2) 

EhA^B EhA<:B EhB<:C 

EhA<:B EhA<:C 

Reflexivity is a special case of (gi). 

It would be natural to require subtyping to be anti- symmetric, hence obtaining a 
partial order. A reasonable semantics of subtyping will in fact construct such a partial 
order. However, it might be too strong to require anti-symmetry as a type rule. In some 
systems anti-symmetry may introduce obscure ways of proving type equivalence, while 
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in other systems it may be provable from the other rules. Moreover, anti-syrmnetry does 
not seem very useful for typechecking, hence we do not include it. 

The basic intuition about subtyping is that it behaves much like the subset relation; 
this is expressed by the subsumption rule, which claims that if A<:B and a is an element 
of A, then a is also an element of B. 

(G3) 

E^a:A E^A<:B 
E\-a:B 

We feel strongly that subsumption should be included in the type system, since this rule 
gives object-oriented programming much of its flavor. One should not be satisfied, for 
programming purposes, with emulating subsumption by explicit coercions. The latter 
technique is interesting and adequate for providing semantics to a language with 
subsumption [Breazu-Tannen Coquand Gunter Scedrov 89] [Curien Ghelli 91], but even then it 
would seem more satisfactory to exhibit a model that satisfies subsumption directly. 

Combining (gi) and (G3) we obtain another standard type rule: 

Eha:A EhA^B 
E\-a:B 

This rule is normally taken as primitive, but here it is derived. 

We are now ready to talk about subtyping between record types. It helps if we break 
this problem into pieces and ask what are the subtypes of: (1) the total record type O, (2) 
an extended record type iR\rAl), (3) a restricted record type RSjc, and (4) a record type 
extraction R.x. 

Case (1). Every record type should be a subtype of the total record type. Hence, we 
have three subcases: (la) the total record type is of course a subtype of itself, and this is 
simply a consequence of (gi); (lb) any well-formed extended record type is a subtype of 
O; and (Ic) any well-formed restricted record type is a subtype of O. Hence we have the 
following rules corresponding to lb and Ic respectively: 

(SI) (S2) 

E^R<:il)\x E^ A type E\-R<:Q 
E\-m\x:AD<:U E\-R\x<:Q 

Case (2). A subtype of an extended record type will be another extended record type, 
provided all respective components are in the subtype relation: 
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(S3) 

E\-R<:S<:Q\x E \- A<:B 



E\-Wx.A}<-AS\x:B} 

The condition A<:5 says that we can produce a subtype by weakening the type of a given 
field. The condition R<:S tells us that we can produce a subtype either (a) by weakening 
other fields inductively, because of (S3) itself, or (b) by requiring the presence of 
additional components, because of (si), or (c) by requiring the absence of additional 
components, for example y, because from (S2) we are able to derive Q\yx <: 0\x. 

Case (3). The subtype rule for restricted types is semantically straightforward: if every 
rinR occurs in S, then every r\x in R\x occurs in S\x: 

(S4) 

E\-R<:S<:Q 
E \-R\x <: S\x 

Remark. Although this rule looks innocent, it hides some interesting subtlety in 
its assumption. Let us analyze R<.S by cases. 

The cases when R and S are themselves restrictions (either of x or of some 
other variable) are straightforward. Similarly simple are the cases when R and S 
are matching extensions, both of them either containing or not containing an x 
field. 

Suppose however that R has a positive x field and S does not, for example 
R-iT\xiAl) and S-T. In that case, if we had R<.S we would erroneously conclude 
that R\x = iT\x-Al)\x ^ T <: 'I\x= S\x (which is false for T=Q). 

Fortunately there was a flaw in this argument; the assumption for (S4) requires 
R = (lT\x:Al) <: T = S, but this is false (for r=OU). Note also that taking 
R=iT\x\x:Al) and 5'=neads to a similar contradiction for T=Q\x. 

A legal instance of the assumption is R = ^Q\x\xA-} <: O = S, from which we 
conclude that R\x - iil)\x\x-Ali\x ^ 0\x <: 0\x = S\x, which is correct. 

Case (4). We have to consider the subtypes of record type extractions; that is 
situations of the form R.x <: T.x, or more generally R.x <: A under an assumption R <: 
(lS\x:Bl). If R can be converted to the form R=(lR'\x:Al), then the extraction simplifies 
and no special rule is required to deduce R.xK'A. But if is a type variable, for example, 
the following rule is necessary: 

(S5) 

E\-R<:iS\x-Al><:Q 
E h R.X <: A 

This says that if R has an x field of type A, theniJ.x is a subtype of A (and possibly equal 
to A). 
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Finally, there is a another subtyping rule that we must consider. If every record rinR 
has an x field, then any such r is described also by the type iR\x\x.R.xl), since r\x is 
described by R\x and the x field of r is described by R.x. Therefore we have the 
following inclusion: 

(S6) 

E\- R<:iS\x-A}<:Q 
E\-R<: (lR\x\x:R.xl) 

The inverse inclusion is not necessarily valid, although it might seem natural to require it 
as we shall see later. 

The rule (S6) can be used in the following derivation, which provides a "symmetrical" 
version of (S5) as a derived rule: 

E\-R<:S<AT\x.Al><:Q 
(S6) E\- S<-AS\x\x.S.xl) 
(G2) E\- R<-AS\x\x:S.xl) 
(S5) E h R.X <: S.x 

In absence of (S6), the derived rule above would have to be taken as primitive, replacing 

(S5). 



3.6 Record typing and equivalence 

Now that we have seen the rules for type equivalence and subtyping, the rules for 
record values follow rather naturally. The only subtle point is about the empty record. We 
must be able to assign it a type which lacks any given set of labels. This is obtained by 
repeatedly applying the following two rules: 

(II) (12) 

\-Eenv E h 0\xj..x^ : R<:Q 

E h {)\xj..x^ : O E\- {)\xj..x^ : R\y 

The remaining constructions on record values are typed by the corresponding 
constructions on record types, given the appropriate assumptions: 

(13) (El) (E2) 

E\-r:R<:Q\x Eh a: A E\- r.R<:Q E \- rM\x-Al!<:Q 

E\-{r\x=a)-AR\xAl) E\-r\x:R\x Eh r.x -.A 

As we did in the previous section, we can use the rule (S6) to derive a "symmetrical" 
version of (i2): 
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E\-r:R<:iS\x-A}<:Q 



(S6) E\- R<M\x\x:R.x} 
(G3) E\- rM\x\x:R.xl) 
(E2) E\- r.x: R.X 

Finally, we have to examine the rules for record value equivalence. These rules are 
formally very similar to the ones already discussed for record type equivalence; record 
extensions can be permuted, record components can be extracted, and restrictions can be 
permuted and pushed inside extensions, sometimes cancelling each other. 

The main formal difference between these and the rules for types is that we equate {}\x 
^ {). Hence, restriction can always be completely eliminated from variable-free records. 

Because of the formal similarity we omit a detailed discussion; the complete set of 
rules for our type system follows in the next section. 

3.7 Type rules 

We can now summarize and complete the rules for record types and values, along 
with selected auxiliary rules. These rules are designed to be immersed in a second-order 
X-calculus with bounded quantification (see [Cardelli Wegner 85]), and possibly with 
recursive values and types. 

We only list the names of the rules that have already been discussed. 

Environments 

(ENV1)...(ENV4), (VAR1)...(VAR4) 

General properties of<: and ** 



(G1)...(G3) 



(G4) 

E\-A^B 



(G5) 

E\-A^B E\-B^C 



E\-B^A 



E\-A^C 



{G6) 

Eha^h-.A 



(G7) 

E\- a ^ h -.A E[-h ^ c -.A 



E\- b *^ a :A 



E\- a*^ c :A 



Formation 



(F1)...(F4) 



Subtyping 



(S1)...(S6) 
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Introduction/Elimination 

ai)...(I3), (El), (E2) 

Type Congruence 

(TCI) 



(TC4) 



5<: O 



(TC2) 

(TC5) 

E^R* 



(TC3) 

E^R 



S<:Q\x E\-A^B 



E\-m\x.Al)^ iS\x.Bl) 
S <: mr.A}<:Q 



E\-R\x^S\x 
Type Equivalence 

(TE1)...(TE8) 

Value Congruence 



E\-R.x^ S.X 



(VCla) 

h E env 
E\-{)^{):Q E\-x 



(VC2) 

E\-x:A 



(VC3) 

E\-r' 



's:R<:Q\x E\-a^b:A 



(VC4) 

ghr^5 :i?<:0 
E \- r\x s\x : R\x 

Value Equivalence 

(VEl) 



-»x : A 

(VC5) 



Eh (Hx=a) ^ (5lx=&) : «i?lxA^ 
5 : R<:iS\x.A])<:Q 



E\- r.x *^ S.X : R.x 



(VE2) 



£■ h r:i?<:0\xy £ h a:A E\-b:B x^ 



(VE3) 

£:h r:R<:Q\x 



E h r\x • 



((rl3;=&)|;t^a) : m\xAl)\y:Bl) 

(VE4) 

£:hr:i?<:0 
£■ h r\xy •«-» Ayx : i?\xy 



E\-{)\x^{):Q 



(VE5) 

£:hr:«i?lx:AK:0 x^^y 



£■ h r\y.x *^ r.x :A 



(VE6) 

E\- r:R<:Q\x E\- a:A 
E h (Hx=a)\x -^r -.R 

(VE8) 

Eh r:i?<:0\;c EhaiA 
£■ h {r\x=a).x a : A 



(VE7) 

£ h r.R<:Q\x 



E h a:A xt^^}; 



E\- {r\x=a)\y^ {Ay\j(^a) : iR\xAl)\y 



(VE9) 



E h r:iR\y.Bl)\x<:il) Eh g-A x^y 
E h (r|j::=a).3; <^ r.y :B 
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(VEIO) 

E\- r.R<-AS\x-Al)<-M 
£■ h r ■«-» {Ax\x=r.x) : R 

Special rules 

In the following sections we discuss the rules (vcib) and (te9) below; these are valid 
only with respect to particular semantic interpretations. 

(VClb) (TE9) 

E\-r.O E\-s:Q E \- R<:<iS\x-Al)<:Q 



E\-r^s:Q E\-R^mx\x:R.xl) 

In presence of (te9), the rule (S6) is redundant, and the rules (tcs) and (vcs) are implied by 
the simpler (xcsb) and (vcsb) below. 

(TCSb) (VCSb) 

E\-R^<iS\x-Al)<:Q E \- r ^ s 'ARlxAlX-.Q 



E h R.X ^ A E \- r.x s.x : A 

Properties 

Lemma 3.7.1: 

(1) If E\-A type, then \- Eenv. 

(2) If E\-A<:B, then h E env. 
Proof 

Simple simultaneous induction on derivations, with (fi) as the base case. 

□ 

Lemma 3. 7.2: 

E\-A^B, then E\-Atype and E\-Btype. 
(2) If EhA<:B, then EhAtype and Eh B type. 
Proof 

Show (1) and (2) simultaneously by induction on derivations. The hardest case is 
(TEi). The next hardest is (tes). All the others are substantially simpler. We prove 
(TEi) below and leave the remaining cases to the reader. 

To prove (1) for (tei), we assume E h R<:ilj\xy and E h A,B type. Using (S2) 
and (S4) we may derive E h 0\xy<:0\x and so by transitivity and (F2) we have E h 
iR\xAl) type. The next goal is to show that iR\xAl) is a subtype of Q\y. Using (S2) 
and (S4) we have E h R<:ili\y by transitivity, and so by (te2), E h R\y ^ R. The 
type congruence rules give E h iR\xA} iR\y\xAl). By (te6) and transitivity we 
now have E h iR\xA} iR\x:A}\y. From (si) and the original hypotheses, it is 
easy to show E h WxAl) <: O and so by (S4), E h WxAljXy <: UXy. This allows 
us to derive E h iR\xAl) <: Q\y, from which we may finally obtain E h 
m\x.A}\yM type. 
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The proof of £ h iiR\y:Bl)\x-Al) type is similar. 

□ 



Sample derivations 

We show the main steps of some derivations that can be carried out in this system, 
assuming rules for typing basic constants. 

The first example simply builds a record of two fields, with its natural type. 

(ID ():0 

(El) {)\x : OU (const) 3 : Int 

(13) {{)\x\x=3) : m\x\x:Intl} 

(El) {{)\x\x=3)\y : (lO\x\x:Intl)\y (const) true : Bool 

(13) {{{}\x\x=3)\y\y=true) : m}\x\r.Intl)\y\y:BooG) 

(def) {x=3, y-true) : ix:Int, y.Booll) 

Next, we derive a non-trivial type inclusion. To construct record types of different 
lengths on the two sides of <:, we start with the basic asymmetry of (si) and we build up 
symmetrically from there (there is no more direct way). 

(Gi) O <: O 

(S4) 0\x<: 0\x 

(SI) m\x\xM <: O 

(S4) iQXxbc-.Int^Xy <: Q\y (gi) Bool <: Bool 

(S3) im\x\xM\y\y:BooB <: m\y\y:Booll > 

(def) hc.Int, y.Booth <: iy.Booth 

Now we show that a given record lacks a given label. This time the key rule is (i2). 
Some type equivalence rules are used to rearrange the type into a standard form. 

(ID ():0 

(12) 0 : 0\y (S2) 0\3;<: O 

(El) {)\x : Q\y\x (S4) (ll)\y\x <: 0\x (const) 3 : Int 

(13) {{)\x\x=3) : m\y\x\x:Intl ) 
(TE3,TC3,Gi,G3) {{)\x\x^3) : (lQ\x\y\x:Intl) 
(TE6,Gi,G3) {{)\x\x=3) : (lQ\x\x:Intl)\y 
(def) {x=3) : ix:Intli\y 

Finally, we show that by removing a label we obtain a subtype. The basic asymmetry 
here is provided by (S2). 
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(Gi) O <: O 

(52) Q\y<: Q 

(S4) Q\^x <: Q\x (Gi) Int <: Int 

(53) m\y\x\x:Intl) <: m\x\x.Intl) 
(TE3,TC2,Gi,G2) iQ\x\y\x.Intl) <. iQ\x\x:Intl) 
(TE6,Gi,G2) iQ\x\x:Intl)\y <: iQ\x\x:Int} 
(def) ix:Intl)\y <: ix'Jntl) 

3.8 Semantics of the pure calculus of records 

Our stated intent is to define a second-order type system for record structures. 
However, models of sucli a system are rather complex, and outside the scope of this 
paper. 

In this section we provide a simple set-theoretical model of the pure calculus of 
records, without any additional functional or polymorphic structure. The intent here is to 
show the plausibility of the inference rules for records, by proving their soundness with 
respect to a natural model. 

This model is natural because it embodies the strong set-theoretical intuitions of 
subtyping seen as a subset relation, and of records seen as finite tuples. Although this 
model does not extend to more complex language features, it exhibits the kind of simple- 
minded but (usually) sound reasoning that guides the design and implementation of 
object-oriented languages. 

Syntax 

We start with the language implied by the type rules of section 3.7. Since no basic 
non-record values are expressible in this calculus, we must make some arbitrary choices 
to get started. To this end, we will consider an extension of the pure calculus with any 
collection Gj , G2 , ... of basic (ground) type symbols and an arbitrary collection of 
subtype relations G, <: Gj between them. To incorporate these new symbols into the 
calculus, we add the following two rules (which preserve lemmas 3.7.1 and 3.7.2): 

h E env h E env 

E h G^ type E h G^ <: Gj (as appropriate) 

For simplicity, we do not introduce value constants; instead we work with environments 
containing assumptions of the form ^ : G, . 

We will now construct a model of the extended calculus. 

Semantic domains 

In the following, we rely largely on context to distinguish between syntactic 
expressions and semantic expressions, and we often identify terms with their denotations. 
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We start by choosing some fixed set of labels L, and a collection of sets , ^2 ' ••• 
corresponding to the type symbols G, , G, , ... such that G. c G. if G. <: G. is a 

1 Z ^ J ^ J 

subtyping axiom. 

For simplicity, we assume that no element of any g. is a finite partial function on L 
(i.e. a record, as we shall see shortly). This assumption is useful when we define the 
subtype relations of sections 3.9 and 3.10. 

Since O serves as a type of all records, we will need some value space closed under 
record formation. This property may be accomplished by regarding records as finite 
functions from L to values, and using ranked values with rank < co. We use A -^^^^ B for 
the set of partial functions from A to 5 with finite domain, j{x) 1 to indicate that the partial 
function/is undefined at x, andj{x) 1 to indicate that/is defined at x. 

Define set ^. of records of rank /, and set '^'.of values of rank as follows: 





= u,^, 


'^i.I = 


^. u V 


% 




^i.l = 


L -fin '^i.l 






the set of records 




1^ 


= U<a,'^- 


the set of values 





The essential properties of this construction are summarized by the relationship: 

It is clear by construction that ^. e and so ^ c "J^. To see that %,=L ^g^l^, we first 
show that L ^^^1^ £ ^. If r e L ^^^1^ , then since dom{r) is finite there is some / with 
range{r) c 1^. ; hence re ^. The converse follows from the fact that if re^, then r e 

We now summarize the notation used to describe the semantic interpretation of 
syntactic constants and operators: 

0 = XyeL. t 

r-x -^^ XyeL. ify=x then t else riy) 

provided re^andxeL 

r[^a] =jg^ XyeL. ify=x then a else r(y) 

provided re Hi,, xeL, ae'V, and x^dom(r). 

r(x) is well-defined, 

provided re Hi,, xeL, and xedom(r). 

Lemma 3.8.1: 

(1) The empty record 0 is an element of 

(2) For any re^iy^Q have r-xe^. 
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(3) If re^ is not defined on x, then for any ael^we have r[x=a]e!l(^. 

(4) If re^ is defined on x, then r(x)e'l/. 

Proof 

(1) The empty function is a finite function. 

(2) If re^then r-x remains a finite partial function in ^. 

(3) Suppose re Hi, with x ^ dom(r), and ael/'. 

Then r[x=a] is well-defined (is a function) and belongs to ^. 

(4) If re^= L — gjj'^'and r(x) is defined then r(x) e 0^. 

□ 

Types and type operations 

Types are interpreted as subsets of our global value set; hence we have a type of all 
values, and a type of all records. Subtyping is interpreted as set inclusion. 
We introduce the following notation for operations on record types: 

R-x =jjgf {r-x\reR} 

if R^tK. 

R[xA] =jg^ {r{x=a] \ reR, aeA} 

if e (R undefined on x) and A e 

R(x) =,^f {Tix)\reR} 

if e S[x-A\ for some 5 e ^ and A e I/' 

Lemma 3.8.2: 

Under the conditions stated above, the sets R-x and i?[x:A] are subsets 
of and the sets R(x) are subsets of 

Proof 

(1) IfR^Hl, then R-x = {r-x \ reR} c ^, by 3.8.1. 

(2) If c ^-x, then is a set of functions re L — ^^^'^'with x ^ dom(r). 
Hence for any A e 1',R[x-A] = {r[x=a\ I reR, aeA} e ^, by 3.8.1. 

(3) If i? c 5[x:A], then for any reR, reS[xA] = [s[x=a] I ^e^, aeA}; 
so that r(x)eA. Hence R(x) = { r(x) I reR} e A e '^1 

□ 

Interpretation of judgments 

An assignment p is a partial map from type variables to subsets of 1/', and from 
ordinary variables to elements of 1^. We say that an assignment p satisfies an environment 
E if the following conditions are satisfied: 

If X in E, then p(X) c 1/ 

If X<:A in E, then p(X) c Ap c 1/ 

If x:A in E, then p(;c) e Ap c 
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where Ap is the type defined by A under the assignment p. Similarly, by ap we indicate 
the value of a term a under an assignment p for its free variables. 

The judgments of our system are interpreted as follows. 

\- E env ~ for every initial segment £",X<:A or £",x:A of 

if p satisfies E' then Ap e 1^ 

E\- A type ~ Ap e 1^, for every p satisfying E. 

E\- A <:B ~ Ap c 5p c I/", for every p satisfying E. 

E\- A B ~ Ap = Bp a, 'U, for every p satisfying E. 

E\- a : A ~ ap e Ap a, 1^, for every p satisfying E. 

E\- a b :A ^ ap = l^p e Ap c 'J^, for every p satisfying E. 

Type and value expressions are interpreted using: 



o 




R\x 


^ R-x 


mx:A]) 


^ R[xA] 


R.X 


R(x) 


0 


^ 0 


r\x 


~ r-x 






r.x 


= r(x) 



Soundness 

Finally, we can show that this semantics satisfies the type rules. More precisely, we 
consider the system SI consisting of all the rules listed in section 3.7, except for the 
special rules (vcib) and (te9). 

Theorem 3.8.3 (soundness): 

The inference rules of system SI are sound with respect to the 

interpretation of judgments given in this section. 
Proof 

See appendix. 

□ 

3.9 A construction giving R = iR\x \x:R.xl) 

The type equivalence rule below seems very natural semantically. It also simplifies 
the types associated with the override operation, and has application to extensional 
models studied in the next section. 
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(TE9) 

E\-R<:iS\x-A}<:Q 
E\- R^(lB\x\x.R.xl) 

In the simple model described in section 3.8, it is easy to see that if e ixAl), then, 
as required by (S6): 

R e m\x\x.R.xl) 

The reason is that every record r in i? has an x component r(x) e R(x), and remaining 
components r-x in R-x. However, it is not necessarily true that every combination of r-x 
from R-x and r(x) from R(x) occur together in a single record in R. For example, the set of 
records: 

R = {{x=l, y=true), {x=0, y=false) } 

is clearly a subset of ix.Intli. However, 7? ^ iR\x\x:R.x} since the records {x=l, y=false) 
and {x=0, y=true) do not appear in R. In category-theoretic terms, the equation R = 
iR\x\x.R.xl) says that R is the product of R\x and R.x. 

In this section we present a variant of the construction of section 3.8 in which rule 
(TE9) is sound. Since we are ultimately interested in polymorphism and bounded 
quantification, we construct a model withi? = iR\x\x.R.xli for every semantic typei? with 
R.x defined. The construction uses the same collection of values as before, but allows 
only certain subsets of as types. In this way we eliminate sets of records which violate 

(TE9). 

We use a value space satisfying: 

^ = (L -^^^ 1^) e 1^ 

constructed as in section 3.8. Then for each natural number /, we define the collection 
of subsets of 1^ which we wish to consider types of stage /. At the first stage, we may 
select any subsets of provided we include the given ground types Q. . For definiteness, 
let us take: 

% = {gj,g2,-} 

We now define record types over preceding types. At each stage we take all record 
types defined by a finite set of labeled component types, and a finite set of absent labels. 
Each component type must belong to the preceding stage. 

This construction may be clarified using an auxiliary definition. Suppose P: L T. 
is a finite partial function from labels to types at stage i, and N Cj-^ L is a finite set of 
labels disjoint from the domain of P. Then the set Hi^'^ of records with components 
present according to P and components absent according to A'^is defined by: 
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= {re^\\/xeL(P(x)i 3 K^)eP(x)) a (xeN 3 r(x)T)} 

We define the set of record types at stage i+1 to be the set of all ad'-^ for suitable 
"present" function P and "absent" set A^: 

= [1^''\P:L ^,^^T. A A^Cg^L a dom{P)r^N=0} u T. 

Note that 5^, = 5^-^ belongs to every T.^^. 
The collection "T of all types is defined by: 

= l^i<.% 

As we have defined % the set l^of all values is not a type. However, it is possible to 
include 1^ in 1^ if desired. 

It is natural to consider any set of records H^'^ with P: L "T and N Cg^^ L, as a 
"record type" over V. Define to be the collection of all record types: 

=,^f { ^^'^ I P: L T, N L, and dom(P)nN = 0} 

Note that = ^ so 5^ has a maximal element. We may show that T is precisely 
the union of 1^ and the record types over 1^; that is T= CZ^ u ^1 

Lemma 3.9.1: 

If P: L T and c^^ L with dom{P)r^N = 0, then e 1 
That is, cl 

Suppose P: L — "T and A'^ e^^^ L. Since the domain of P is finite, 
there is some / with P: L 1. . Hence, e T.^j e T. 

□ 

In this model we will interpret all judgments as before, except that type variables and 
type expressions must denote elements of T. Since we consider only elements of "Tas 
types, we define the relation A e: 5 (A semantic subtype of B) as: 

Ae:B iff Ae5andA,Be'r 

By the simplifying assumption in section 3.9 that no ground type contains records, we 
know that every subtype of ^will be an element of H^. If we had not made this 
assumption, then we might have some subtype of ^which "accidentally" could cause 
(TE9) to fail. 

We may show that for any non-empty R e a function P and set A'^ with R = H^'^ are 
determined uniquely. 

Lemma 3.9.2: 

Let P e be non-empty. Then R = ^■'^ where: 
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dom(P) = {xeL I Vrei?. r(x)i }, 

A^= {xeL\\/reR. r(x)t},and 
P(x) = R(x) for all xedom(P) 

Proof 

Suppose R e ^ is non-empty and let rg'^R- 
We know that R = for some P,N. 

(1) By construction of !S^-^ we have \/reR. dom(P) e dom{r). 
Moreover, if \/reR. r(x)i, then xedom(P), since xidom(P) implies 
rg-xeR and (rQ-x){x) 1 . Consider the function/defined by: 

J{x) = rgix) if \/reR. r(x)i, and t otherwise 
This function belongs to R, and domif) = {xeL I \/reR. r(x)i } c dom(P). 
Hence dom(P) =dom(f) = {xeL I Vrei?. r(x)i}. 

(2) By construction of i^-^ we have \/reR.N^ T(r) =jgj {xeL I r(x)t }. 
Moreover, if \/reR. r(x)T , then ^ceA?^ (since x^N implies either rQ(x)i 
or (rQ[x=a])(x)i for an appropriately chosen rQ[x=a]eR). 

Choose fromi?_^ =^^^ { reR I r(x) i } whenever R^ ^ 0, and define: 

g(x) = t if \/reR. r(x)t , and r^(x) otherwise 
This function belongs to R and t(g) = {xeL NreR. r(x)t } c A^. 
Hence, iV= T(g) = {xeL I Vrei?. r(x)t }. 

(3) Assume xedom(P). 

R(x) = !H^'"(x) ={rix)\ reHl , \/yeL. riy)eP(y) } (since x^N) 
= {rix)\ reHl , r(x)ePix)} ^{ae'U\ aeP{x)} = P{x) 

□ 

This allows us to write each non-empty record type R e as fK^-^ without 
ambiguity. The lemma also demonstrates that whenever R(x) is defined, R(x) - ^•'^{x) = 
P(x) e "T is a type. 

It is now straightforward to show that the record types are closed under restriction (R- 
x) and extension (R[x:B]y. 

Lemma 3.9.3: 

lfR = H^-^ is any record type, then R-x = ^ , where 
P' = P - {<x^-^P(x)>} if P(x)i, and P otherwise. 
N' = N (J {x} 

Proof 

Straightforward. 

□ 

Lemma 3.9.4: 

lfR = withxeA^, and5e % then R[x:B] = , with: 
P' = P u {<;c^B>} 
N' = N-{x} 
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Proof 

By definition, R\x:E\ = {r[x=b] I reR, beB}. It is easy to check 
that every r[x=Z7] belongs to H^'^' and conversely. 

□ 

The semantic subtyping relation on record types R ^: R' is now determined by the 
present and absent information. 

Lemma 3.9.5: 

^.N^.^'.N' iff 

\/xedom(P'). P(x)i a P(x)^:P'(x) 
N' ^ N 

Proof 

Assume ^^-^e: 

It is easy to check that N' ^ Nby the definition of 5^ 
Similarly, if P'(x)i then we must have P(x)i a P(x) e P'(x). 
By definition P(x) and P'(x) are types. 
The converse is straightforward. 

□ 

Since the point of this model construction is to give R = (R-x)[x:R(x)] for every record 
type R with R(x)i, we must also prove this equation. Given the preceding lemmas, the 
proof is almost immediate. 

Lemma 3.9.6: 

Let R e be a record type with r(x) 1 for all reR. 

ThenR = (R-x)[x:R(x)]. 
Proof 

We know R = f^^-^ for some finite function P and finite set A^. 
By preceding lemmas, we also have: 
R-x = 

(R-x)[x:R(x)] = H^"'''" 
wi±P' = P- {<x^R(x)>}, N' = Nu {x} 
and P"=P'u {<x^R(x)>}, N" = N'-{x}. 
Since P" = P andN" = N, it follows that R = (R-x)[x:R(x)l 

□ 

Finally, we have the soundness theorem. System S2 is system SI of Theorem 3.8.3 
plus the rule (te9). 

Theorem 3.9.7 (soundness): 

The inference rules of system S2 are sound with respect to the 
interpretation of judgments given above. 
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Proof 

See appendix. 

□ 



3.10 An extensional model construction 

The following inference rule gives us an extensional equality between records: 

(VClb) 

The intuitive reason for adopting this rule is that if r and s both belong to O, then r 
and s are indistinguishable. In fact, assume r and s differ at some label x. We cannot use 
r.x or s.x to distinguish them since neither is well-typed; if we use r\x or s\x then we 
simply remove the difference. 

In addition to giving us more equations between records of type O, rule (vcib) implies 
the following extensionality property: for any r,s : ixj'Aj , ... , Xj^'AjJ), we have r «-» s : 
(Ixj'Aj , ... , Xj^'A/J) iff r.Xf'^s.x^ : A, for / = l...k. The straightforward proof of this uses 
r\xj...x^. s\xj...x^. : O and the value congruence rules. 

Recall that in the previous models a record type was simply a set of records, and 
equality of records was independent of the type. Therefore, any two distinct records 
would be unequal elements of O, causing (vcib) to fail. 

In this section, we will construct a model of the pure record calculus satisfying (te9) 
and (vcib). It will be clear from the construction that (te9) is essential; we do not know 
how to construct an extensional model satisfying (vcib) without requiring that record types 
satisfy R = ^R\x\x:R.x} . The main use of {te9) lies in showing that if i? is a record type 
with extensional equality, then both R-x and R(x), when defined, are extensional record 
types. 

We begin with a value space l^satisfying: 

^ = (L 1^) ^ 1^ 

constructed as in section 3.8, and define types as certain partial equivalence relations 
(abbreviated PER's) over 1/ (see [Longo Moggi 88]). A PER is a binary relation which is 
symmetric and transitive, but not necessarily reflexive. An element of a type is defined as 
an equivalence class of values in the PER. 

Subtyping is based on set containment of partial equivalence relations, as in [Bruce 
Longo 88], except that we consider only certain PER's as types. 

The type of all records O is interpreted by the PER ^x^. This type has only one 
element since there is a single equivalence class in : while O contains all records, 
all records are equivalent in O (hence (vcib) holds). 
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The three operations on record types are defined as follows: 

• If is a PER on ^ with r(x) t for every record rRr, and A is a PER 
on 1^, theni?[x:A] is the relation on ^ given by: 

r i?[x:A] s iff r-x R s-x and r(x) A s(x) 

In writing tix) A s(x) we imply that r(x)i and s(x)i . 

• If i? is a PER on ^ , we define the relation R-xhy. 

R-x =jgj. [<r-x, s-x> I rRs} 

• If i? is a PER on ^ , with r(x) i whenever rRr, we define the 
relation R(x) by: 

R(x) =def {<rix), s(x)> I rRs} 

It is easy to show that under the hypotheses above, i?[xA] is a partial equivalence 
relation on 5^. However, R-x and R(x) are not necessarily transitive. This will not cause 
any problems, as it turns out, since by restricting the class of record types to some 
collection satisfying (te9), R-x and R(x) are guaranteed to be types (and hence PER's). 

The types over l^will be defined in stages, as before. We begin with some collection: 
% = , £2 ' ••• } 

of partial equivalence relations over 1^ that do not relate any records to themselves. A 
typical choice would be to begin with the identity relations on the ground types , ^2 ■> 

Given any finite partial map P from L to PER's over 'J^and a set N L disjoint from 
the the domain of P, we define the PER i^^'^ over by: 

rH^-^s iff VxeL. 3 r(x) P(x) s(x)) A (xeN Zi r(x)TAs(x)t) 

Note the similarity to for subsets of 1^ ; if we represent a subset S^'f by the PER 
(SxS) e the two definitions coincide. It is easy to see that if each P(x) is a PER, 

then so is 1^'^. 

Following the earlier definition of record types in stages, we define: 

= {^■^\P:L^^^r. A N^^^L A dom(P)nN=9i} u % 

and let: 

This construction has much the same character as the previous non-extensional one, 
although we have the added complication of establishing that R-x and R(x) (when 
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defined) are PER's whenever iJeCT Since every ReTis easily seen to be a PER, we will do 
this by showing R-xeTand R(x)e'T. 

It is easy to prove Lemma 3.9.1 for this model, showing that we need not consider 
stages of the construction in later arguments. 

Lemma 3.10.1: 

If P: L -j.^ T and e^j^ L with dom(P)r^N 

Define the collection of all record types by 
Subtyping is interpreted as before, with: 

Ae:B iff AeBandA,Be'r 

We now use present functions and absent sets to show that for every R e we have 
R-xe^and R(x)eT if r(x)i for every rRr. 

Lemma 3.10.2: 

If Re ^^^r, then iJ-xeT. 

If Re !H!X with r(x)i whenever rRr, then R(x)e'T. 

Proof 

The lemma is trivial if R= 0, hence we assume R^ 0. 

(1) Let i?=^^^ Then R-x = 1^'^' with P' = P - [<x^P(x)>} and 
N' -Nu {x}. To see this, suppose r R-x s. Then there must 
be records r'.^'e^ with r'Rs' and r=r'-x, s=s'-x. 

Since ^ r(y) P(y) s(y) and yeN' 3 r(y)\ a s(y)\ , 

it follows that r s. 

To show the converse, we assume r ^ s and note that since 
R^ 0, there must be some ^el^'with b P(x) b. It is easy to see 
that r\x=b] R s\x=b], and sorR-xs. 

(2) We now assume r{x)\ whenever rRr. Since R=HC'^ , we have 
P(x)e'r It remains to show that R{x)=P{x). If a R(x) b, 
then there exist r and 5 with rRs and (3=r(.x:), Z7=s(x). 

By definition of 5^^^ it follows that a P(x) b. 

For the converse, we assume a P(x) b; since R^ 0, there exist 

r and 5 with r s and r(x)=a, s(x)=b. Hence a R(x) b. 

□ 

Lemma 3.10.3: 

If Re with r(x) t whenever rRr, and ^eCZ^ then i?[x:5]eT. 
Proof 

The lemma is trivial if R= 0. Otherwise, we let R=!!^-^ and show that 
i?[x:5]=C'^ withP' = P u {<x^B>} andN'= N-{x}. 
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= 0, then !!^-^eT. 



This is straightforward. 

□ 

It is now an easy matter to show analogs of Lemma 3.9.2 and Lemma 3.9.6. These 
conclude the basic properties of the construction. System S3 is system SI of Theorem 
3.8.3 plus the rules (te9) and (vcib). 

Theorem 3.10.4 (soundness): 

The inference rules of system S3 are sound for the PER model 
construction. 

Proof 

See appendix. 

□ 

3.11 The update operator 

Extensional models are useful to characterize a natural form of record update, here 
denoted by r.x :- a for functional update. The discussion is also relevant to the typing of 
imperative update, r.x := a, although our models do not directly capture side-effects. 

The functional update operator cannot be introduced by a simple definition. We want: 



r.x :- a {Ax\x=a) 

but only provided that r.x exists, and that r.x :- 
Sufficient assumptions are that r:R<:Q and 
typing: 

E\-r:R<:Q 
(El) E h r\x : R\x E h a:R.x 



a does not modify the type of the x field. 
a:R.x; then we can derive the following 



ai) E\- {Ax\x:=a) : iR\x\x:R.xll 
(def) E\- r.x -.-a : iR\x\x:R.xl) 

This is not quite satisfactory, because we would expect the result type to be R, 
meaning that the type of a record is not modified by updating one of its fields (with a 
value of the correct type). 

Fortunately, by using (te9) {iR\x\x:R.xl)<^R) we can derive the expected type rule: 

(UPD) 

E\-r:R<:Q E\- a:R.x 
E\- r.x :- a : R 

This seems to be a compelling reason for adopting (te9), because of its impact on such an 
important operator as updating. 
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Note that the (upd) rule is very strong; it applies even when is a variable. From it we 
can derive a perhaps more natural but less general rule: 

(UPD') 

E\-r.m\x:A}<:Q E\-a-A 
E\-r.x:-a : iR\x.Ali 

Remark. Here we might be tempted to weaken the assumption to £ h a:A'<-A, 
and strengthen the conclusion to £■ h r.x :- a : iR\x-A'l). This is valid but 
undesirable, since we might then be unable to update the x field again with its 
original contents. 

The strong (upd) rule would not be expressible without R.x types; the following 
apparently natural variation is unsound: 

E\-r.R<:(lS\xAl) E \- aA 
E\- r.x :- a : R 

For example, takeA=Bool, R=ix:Truel), and r={x=true); then from r.x:Bool aadfalse:Bool 
we can derive r.x:-false : hc:Truel). 

3.12 Normalization and decidability 

Even though the basic ideas behind the record calculus are relatively simple, the 
formal system has quite a few rules. As a consequence, it is not easy to see, by inspection, 
how we could determine whether a supposed type A is well-formed, or whether a record 
expression has type R. 

In this section, we show that all of the basic properties of the calculus are decidable, 
using relatively natural algorithms. In the process, we show that every type expression 
has a unique normal form (modulo permuting the order of fields) and every typable 
record expression has a principal type in each suitable environment. 

The first properties we consider are deciding whether a supposed environment E is 
well-formed and whether a given A is a well-formed type expression in E. A quick glance 
at the formation rules shows that in order to determine whether a type is well-formed we 
must be able to decide the following apparently simple properties; assuming E\- R type is 
derivable, we want to know whether E h R<:Q\x and whether there exist S and A such 
that E h R<:iS\xAli. Therefore, we consider these first. Once we develop a simple 
method for these, it is easy to check whether a type or environment is well-formed. 

For each derivable E\- R type, we define a labeled tree Tree(E h R type) with: 

edges: labeled by field names 

vertices: labeled by finite sets of field names 
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If V is a vertex in Tree(E h R type), we call the finite set of field names at v the absent set 
at V. 

Intuitively, ifp = x^x^ ... x^ is a path from the root of Tree{E h R type) and A'^ = {yp 
is the absent set of the vertex designated by this path, then: 

E\- {..{R.Xj).x^ ... ).Xj^ type 
E\-UR.Xj).x,...).x^<: Q\yjy2...yi 

A convenient notational shorthand is to write R.p for (..(^.^^^.^2 •• ^-^/t' where p is the 
path p = XjX^ ... Xj^. If p = 8 is the empty path, then we may write i?.£ for R. If e is an edge 
leading from the root of a tree to the root of some subtree, we call e a root edge. 

We define Tree(E h R type) by induction on the length of E. If E has length 0 then R 
must be the type constant O. In this case, we define: 

Tree(0 h O type) = single node with empty absent set. 

For context E = E',X<-A we use induction on the form of type expressions: 

Tree{E\- Ytype) = Tree(E'\- Y type) for Y 

Tree(E\-Xtype) = Tree(E' \- A type) 

Tree(E h iS\x:B]) type) is obtained from 

T = Tree(E h S type) and T' = Tree(E h B type) 
by making T' a subtree of the root of T along a root edge 
labelled x, and removing x from the absent set of the 
root of T (if there). 

TreeiE h S\x type) is obtained from Tree(E h S type) 

by deleting the subtree along the root edge labeled x (if there), and 
adding x to the absent set of the root. 

Tree{E h S.x type) is the subtree of Tree(E h S type) 
located along the root edge labeled x. 

For context E = E',X the definition of Tree{E h R type) is the same as above, except for 
the following case: 

Tree(E,X h X type) = empty tree. 
For context E = E',x:A we let: 

Tree(E h R type) = TreeiE' h R type) 
This concludes the definition. 



Page 37 



In the clauses defining Tree(E h iS\x:B} type) and Tree(E h S.x type), we have 
assumed certain properties of Tree(E h S type). These are justified by the following 
lemma. 

Lemma 3.12.1: 

Suppose E\- R type and let T= Tree(E h R type). 

(1) If p is a path in T, then E h R.p type. 

(2) If X is in the absent set of T at position p, then E h R.p <: Q\x. 
Proof 

Induction on the derivation of T. 
Case 0 h O type. Trivial. 

Cases E',X<:A h Y type and E',X\- Y type with Y^X. 

Induction hypothesis and the property that if E\- J for 

any judgment J, and E,E' env, then E,E'\- J. 
Case E',X<:AhXtype. 

By induction hypothesis E'\- A.p type and E' h A.p <: OVc. 

The conclusion follows by repeated use of (F4) and (S6), and 

transitivity of <: . 
Case E',X \-X type. Vacuous. 

Cases E',X<:A h ^S\y.Bl! type and E',X h iS\y:Bl! type. 
Case p = e. (1) is trivial. 

(2) by induction hypothesis E\- S <: Q\x for x in 
the absent set of T(xity). Hence, E h ^Slyifi^ <: OVc. 
Case p = yp'. Use (te?) and induction hypothesis for E\- B type. 
Otherwise. Use (tes) and induction hypothesis for £■ h ^ type. 
Case E',X<-A h S\y type and E',X h S\y type. 
Case p = 8. Two subcases: 

Case x=y. Since E h 5\y fype must follow from (F3), we must 

have E\- S <: Q. The result follows by (S4). 
Case x^. Then x must be in the absent set for Tree(E h S type) 
and so £■ h 5 <: OU. By (S4), £■ h S\y <: 0\xy, and we 
know that Q\xy <: 0\x 
Case p^e. Then p must be a path in Tree{E h 5 fyp^) not beginning 
with y. It follows from the induction hypothesis that 
E h 5'<: iT\zAl) for z^^^iy the first symbol of p. By (te4), we have 
E\- S.Z'^ S\y.z, and the lemma follows by the congruence rules. 
Cases E',X<:A h S.y type and E',X h S.y type. 

Straightforward from induction hypothesis. 
Case E',x-A h R type. By induction hypothesis. 

□ 
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The preceding lemma shows that the path and absent information provided by Tree(E 
h R type) is "sound" with respect to the proof rules of the calculus. Since the proof rules 
are sound with respect to our semantics, it follows that the assertions of the form E h 
R<:0\x and 35,A. E \- R<:iS\x:A]) determined from Tree{E hi? type) are semantically 
sound. 

We may also show that the assertions are semantically complete. It follows from the 
preceding lemma that the proof rules are also semantically complete for deducing 
assertions of the form: (1) £ h R<:Q\x, and (2) if there exists S and A with R<:iS\x'A} in 
every assignment satisfying E, thenE h R<:iS'\x:A']) for some 5" and A'. 

Lemma 3.12.2: 

Suppose E\- R type and let T= TreeiE h R type). 

There is a semantic model f?lfand assignment p such that: 

(1) If p is a sequence of labels which is not a path in T, then there 
is some record r in R^ with r.p undefined. 

(2) If /7 is a path in T with x absent from every record in {R.p)p , 
then X is in the absent set of T at the vertex located at p. 

Proof 

We may use the model constructed in section 3.8 using a single 
ground type ^=N, for example. For each environment E, we define 
an assignment such that whenever E\- R type, there is some reR 
with r.p i iff p is a path in Tree(E h R type). (This is straightforward.) 
It is easy to verify that for any vertex v in any TreeiE h R type), if x is in 
the absent set at v, then there is no child along any edge labeledx. 
This and (1) imply part (2) of the lemma. 

□ 

By constructing trees of absent sets, it is relatively easy to decide whether a purported 
environment or type expression is well-formed. The basic idea is simply to check whether 
h E env ox E\- R type by reading the environment and formation rules backwards. This 
gives us mutually recursive procedures which rely on Tree(E h R type) in checking the 
hypotheses of (F2) and (F4). 

Theorem 3.12.3: 

Given environment E and expression A, there are mutually 
recursive procedures which decide whether h E env and E\- A type. 

The next problems to consider are, given well-formed types E \- A type and E \- B 
type, whether E h A*^B orE\- A<:B. Since type equality may be used to prove subtyping 
assertions, both depend on our choice of type equality rules. For definiteness, let us 
assume we have (te9). Similar results seem to hold without (te9), but we have not checked 
the details. 
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If E\- R type, then it is evident that by directing type equality rules, we may rewrite R 
to one of the following "normal" forms: 



(1) O 

(2) X (a type variable) 

(3) (..(Rq-Xj) ... .x)\yj ■■■ Jj where R^ is either O or a type variable. 

(4) iR^j ... x\yfA^ ... yj-Aj) where, considering T = Tree{E h R type): 

• Rq is either O or a type variable; 

• >';••• J, are exactly the labels on the root edges of T; 

• {x, ... x] - [y , ... y.} is the absent set at the root of T; 

• A, ... A. are also in normal form. 

In the semantics of section 3.9, the meaning of a type expression of form (4) is a 
record type where N={x, ... x.} - {y, ... y.}, dom(P) = {y, ... y.}, and P(y ) is the 

1 I 1 J I J n 

meaning of A^. Since we may construct models in which no type is empty, and 
assignments in which each type variable denotes a different type, we may show that two 
type expressions are provably and semantically equal iff they have the same normal 
forms, modulo differences in the order of field names and component types. By lemma 
3.9.5, we may also see that, semantically: 

(IRq\Xj ... x^\yj-Aj ... y:.Ap c: iS^u^ ... Uj}Vj:B^ ... v(.B) 
iff 

. ({m^ ... u^} - {Vj ... V,}) e ({Xj ... X.} - {yj ... yj}) 

• {v^ ... c {yj ... y.} 

. if V = y then A e 5 

This property allows us to decide semantic subtyping by normalizing type expressions, 
comparing outer-most forms, and recursively examining corresponding component types. 
Since all of the steps of the algorithm correspond to derivations in the proof system, 
completeness of the proof rules (for type equality or subtyping assertions) follows. 

Theorem 3.12.4: 

Given E \- A type and E \- B type, there are straightforward algorithms 
to determine whether E h A'^B or £ h A<:B. Moreover, the proof rules 
are semantically complete for deducing type equality and subtype 
assertions. 

The final algorithmic problem is, given E \- R type and an expression r, determine 
whether E h r:R. 

Since we can decide whether one type is a subtype of another, it suffices to compute a 
minimal type S with E h r.S and check whether E h S<:R. 
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However, most record expressions do not have a minimal type. This stems from the 
fact that for any sequence ... x^, of labels, we have 0 : 0\Xj ... x^, , and we can always 
obtain a smaller type by adding more labels. To get around this problem, we use type 
schemas that contain sequence variables. We show that each typable record expression r 
has a scheme S such that every type for r is a supertype of some instance of S. This allows 
us to test whether a record expression has any given type. We use /, ... for sequence 
variables in schemas. 

If S is any scheme with sequence variable /, then we say E\- S type if £■ h 5" type for 
every S' obtained by replacing / with a sequence of labels (including the empty sequence). 
li E \- S type, then a useful algorithm is MakeAbsent(x,S) which attempts to compute a 
substitution instance S' (possibly containing sequence variables) such thatfi h 5'<:0\x If 
such an instance exists, MakeAbsent{x,S) returns the smallest one. If no instance exists, 
the algorithm /a//s. (Algorithm MakeAbsent uses an extension of Tree(E h R type) to 
schemas; details are straighforward and omitted.) 

Using MakeAbsent, we may compute a principal type schema PTS(E,r), for any well- 
formed environment £■ and expression r, as follows: 

PTS(E, 0) = 0\/ (where / is a fresh sequence variable) 

PTS(E,x) = E(x) 

PTS(E, r.x) = PTS(E, r).x if defined, else fail 
PTS(E,r\x) = PTS(E,r)\x 

PTS(E, {r\x=a)) = iMakeAbsentix, PTS(E, r))\x:PTS(E, a)} 
Theorem 3.12.5: 

Given h E env and an expression r,\fE\- r:R then PTS{E,r) succeeds, 
producing S with E\- S'<:R for some instance S'ofS. Otherwise, 
PTS(E,r) fails. Furthermore, given S = PTS(E,r) and E \- R type, it is 
easy to compute the smallest instance S' of S such that if any instance 
is a subtype of R, then E h 5"<:^. 

This concludes our investigation of decidability properties. We leave extensions of 
these properties to functions and polymorphism for further work. 

4. Applications and extensions 

One might ask why we should go to the trouble of defining the subtle extension and 
restriction operators, instead of adopting the override operator as a primitive, as in [Wand 
89]. In particular, our explicit handling of negative information seems to introduce much 
complexity. 
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One answer is that negative information seems necessary to a proper understanding of 
the override operator. For example, the notion of absent fields is critical to Remy's 
account of overriding in [Remy 89]. Hence, it seems worthwhile to investigate negative 
information as formalized by a separate operator. 

A more pragmatic answer is that overriding really performs two different actions in 
different situations; it either extends a record or updates it. From a methodological point 
of view, a single override operator is rather undesirable because it may silently destroy 
information. A separate extension operator is preferable, because a type error occurs if we 
attempt to use it to destroy an existing field. A separate update operator is also preferable, 
because normally we do not want to update a field with a value of a totally different type. 

Hence, in a programming language we would probably want to replace the override 
operator by two separate operators: one for extension, which we have, and one for 
updating, discussed in section 3.11. The restriction operator could still be used when we 
really intend to delete a field. 

Admittedly, restriction is still ambiguous, because it may or may not remove a field, 
depending on whether the field is actually present. It is however possible to define a safe 
restriction operator which produces a type error if the restricted field is not present. 
Unfortunately, we could not find a way of completely eliminating the need for general 
restriction (at least on types); this operator seems necessary to express crucial well- 
formedness conditions. 

This said, we are now ready to investigate some useful derived operators. 

4.1 The override operator 

The override operator (r <— x=a) =^^^ {r\x\x=a) is certainly very natural, in fact we 
have used it almost exclusively in our examples. The derived type rules for this operator, 
described below, are also very simple, especially if we consider the subsystem with only 
overriding and extraction. The rules mixing overriding with restriction are still rather 
interesting. 

We recall the definition of the override operator: 

(r «- x=a) =jjg^ {Ax\x^a) 
iR^x-All iR\x\x.All 

The following rules are all simply derivable from the rules for our basic operators (we 
assume (te9)); with these, extension need not be a primitive. 

Formation 

E\-R<:Q Eh A type Eh R<:iS^x:Ali<:il} 

E h iR^x-.Al) type E h R.x type 
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Subtyping 

E\-R<:Q Eh A type E\- R<:S<:Q E\-A<:B 



E h m^x:Al) <:Q E\- m^rAl) <: (iS^x-M 

E\-R<:(lS^x:AD<:Q E\- R<:(lS^r.Al)<:U 

E\-R.x<: A E\-R<: (lR^x:R.xl! 

Introduction/Elimination 

E\-r.R<:Q Eh a: A E \- r-M^x:Al)<:Q 



E V- {r^x=a) : iR^x-Al) Ehr.x:A 
Type Congruence 

E\-R^S<-A1) E\-A^B E\-R^ ^S^x:Al!<:Q 



E h iR^x:Al) ^ iS^x-M EhR.x^A 
Type Equivalence 

E\-R<:Q E\-A,Btype x^y Eh R<:iS^x-Al}<:ill 



E h UR^xAl)^y:Bl) ^ UR^yM^xAl) E\-R^ m^x:R.xl) 

E\-R<:Q EhAtype E\-R<:Q Eh A type x^y 



E h (lR^xAl)\x ^R\x Eh (lR^xAl)\y ^ my^xAl) 

EhR<:Q Eh A type Eh R<-AS^y:Bl)<:Q Eh A type x^y 



E h iR^xAlx A Eh iR^xAly R.y 

Value Congruence 

Ehr^s:R<:Q Eha^b:A E h r ^ s : iR^x-Al><:Q 



E h {r^x=a) «-» {s*-x=b) : iR*-xAl) Eh r.x-^ s.x : A 

Value Equivalence 

Ehr:R<:Q EhaA Ehb.B x^y 

Eh{{r^x^a)^y=b) ^ {{r^y=b)^x=a) : (im^xAl)^y:Bl) 

Ehr:R<:Q EhaA Ehr:R<:Q EhaA x^y 



E h {r^x=a)\x «-» r\x : R\x E h {r^x=a)\y «-» {Ay^x=a) : iR'^xA^Xy 

Ehr:R<:Q EhaA E h rM^y:Bl)<-M EhaA xty 

E h {r^x=a}.x ^ a : A Eh {r^x=a).y r.y : B 
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E\-r:m^x:A}<:Q E \- r.R<-AS^x-Al)<:Q 



E h r\y.x ■«-» r.x : A £ h r (r<-x=r.x) : R 

4.2 The rename operator 

We may consider a rename operator, that shows another interesting use ofR.x types. 

r[x-«-3;] =^gj {r\x\y=r.x) 
=^^^ iR\x\y:R.xli 

The rules for this operator are easily derived. The only interesting questions are whether 
renaming with an identical variable produces an equivalent value or type: 

R{x^x] ^ R ? 
These equivalences are derivable for arbitrary r and R, by using: 

(VEIO) (TE9) 

E h r:R<-AS\x:Al)<:Q E h R<:iS\x:AD<-iD 



E\- {Ax\x=r.x) : R E\-R^ iR\x\x:R.xl) 

Recall that (veio) is satisfied in all our models, but {te9) only holds in the latter two. 
These are similar to the surjective pairing rules in X-calculus. An alternative, not 
involving surjective pairing, is to axiomatize the renaming operators independently. 

4.3 The retraction operator: forgetting information 

We have seen that even negative information should be considered as "additional" 
information. So, one might ask whether there is any way to retract information, both 
positive and negative. This would seem to be more a convenience than a necessity, since 
one could avoid introducing information in the first place, rather then retracting it later. 
However, it is still interesting to investigate the possibilities. 

We have not been able to formulate operators that independently retract positive and 
negative information, but we can describe an operator that retracts all information about a 
given label in a type. This operator works purely on type information; there is no 
corresponding operator on values. 

The retraction operator, R~x, means "forget everything about x in record type R"; the 
following rules enforce the cancellation of all the x information in R. 

Formation/Subtyping 

E\-R<:Q E\-R<:S<:Q E\-R<:Q 



E\-R~xtype E\-R~x<:S~x E\-R<:R~x 
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Type Equivalence 



\-Eenv E\-R<:Q E\-R<:Q 



E\-Q~x^Q E\-R~xx^R~x E\-R~xy^R~yx 

E\-R<:Q E\-R<:Q x^y 



E h R\x~x ^ R~x E h R\x~y ^ R~y\x 

E\-R<:Q\x Eh A type E\- R<:Q\x Eh A type xty 



E V- iR\x.Al)~x R~x E h iR\x.Al)~y ^ iR~y\x.Al) 

The main consequences for values involve the rule R <: R~x together with the 
subsumption rule: if r.R, then we are allowed to forget some information about r and 
conclude r.R~x. 

Here are some interesting inferences: 

E\-R<:Q E\-R<:Q 



E h R~x<: Q~x E\-r.R E\-R<: R~x 

E h R~x<: Q E\-r :R~x 

E\-r:R E \- r : R <: Q\x Eh a 



Ehr\x:R\x Eh {r\x^a) : iR\xAl) 



Eh Ax: R\x~x E h { r\x=a) ■AR\xAl)~x 



Eh r\x: R~x E h {r\x=a) : R~x 

The conclusion Ax : R~x above seems to say that restriction on values can be seen as a 
retraction operator, as well as a restriction operator. 

Going back to a previous example from section 2.5, we can see the usefulness of the 
retraction operator for defining hierarchies in "inverse" order: 

let ColorDisc = ix:Real,y:Real, r.Real, c.Color} 
let ColorPoint = ColorDisc~r 
let Disc = ColorDisc~c 
let Point = ColorPoint~c 

Note that the restriction operator would not produce the desired results. 



4.4 The concatenation operator 

Concatenation is a prime candidate for a primitive operator for a calculus of records. 
Unfortunately this operator is very difficult to handle; so difficult that we have instead 
chosen extension and restriction as our primitive notions. Here we discuss the main 
problems. 



Page 45 



Type hierarchies are naturally expressed by a concatenation operator II S on types; 
for example we would like to define: 

let ColorDisc = ColorPoint II Disc 

Given a corresponding operator of values, r II 5 of type i? II 5 for r.R and s:S, we would 
like to guarantee that if we can derive r II 5 : II 5 then there is a succesful and 
unambiguous way to execute r II s at run-time. 

Under these conditions, we can see that concatenation is in fundamental conflict with 
the subsumption rule. Consider the function: 

letfl{X<\ix\Intll){Y<\iy-.Boo^){rX){s\Y) ■.X\\Y=r\\s 
fl(<lx:Int,z:Intl>)(iy:Bool,z:BoolMx=3,^4))(b(^3,z=true)) ? : ? 

There is no explicit conflict in the definition of /i , so it should typecheck. But when 

fl is used as above, we have to decide which z field to produce, both in the result type and 
in the result value. A popular choice is to have X II 7 perform a left- to-right (or right-to- 
left) overriding of common fields; similarly for r II 5 at run-time. However, run-time 
overriding can run into difficulties: 

letf2{rAx:Intl)){s:iy:Boolli) : ir.Int, y.Booll) = r\\s 
f2i{x^3,y^4))({y^true,x^false)) ^ ? 

Let us assume here that, whatever definition we give to II, it satisfies the equation: 
^x:Intl)\\ iy.Boolli = ix:Int, y:Boo§; then f2 is well-typed. Could we use run-time 
overriding in the invocation of f2 above? According to the result type of f2, the left x 
should override the right x, while the right y should override the left y, so monodirectional 
overriding will not work. 

An option here is to give a run-time error, but this seems to defeat the purpose of 
typechecking r II 5. Another option might be to compile special code for r II s, according to 
the types of r and s, so as to pick the x field from r and the y field from s, and to do 
overriding on the additional fields (to deal with the polymorphic case, below). This idea 
however runs into further difficulties: 

fl{1x:Int, y.Int, z:Intli){iy:Bool, x:Bool, z.Booftl) 

{{x=3, y-4, z^4))({y-true, x=false, ZF^true)) ^1:1 

If X\\ Y is computed by overriding, here, we get the wrong result. Making XII F 
compatible with the behavior of r II above, would require violating some basic rules, 
such as the beta-conversion rules for type parameters. 

Because of all these difficulties, we should now feel compelled to define R\\ S only 
when R and S are disjoint: that is when any field present in an element of R is absent from 
every element of S, and vice versa. Unfortunately, there is no way to axiomatize this 
notion without drastically changing our type system: any two record types R and S have a 
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non-empty intersection, and an element of this intersection can be exhibited via the 
subsumption rule. 

5. Conclusions 

We have investigated a theory of record operations in presence of type variables and 
subtyping. The intent is to embed this record calculus in a polymorphic X-calculus, thus 
providing a full second-order theory of record structures and their types. Although we 
have not investigated the type inference problem for this calculus, we have provided 
typechecking and subtyping algorithms. We have also presented several models of the 
basic record calculus; a full second-order model is left for future work. 

The result is a very flexible system for typing programs that manipulate records. In 
particular, polymorphism and subtyping are incorporated in full generality. We expect 
that this theory will be useful in analyzing fundamental aspects of object-oriented 
programming. 
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Appendix 

This appendix contains soundness proofs for the semantic interpretations given in the 
paper. 

Semantics of the pure calculus of records 

System SI consists of all the rules listed in section 3.7, except for the special rules 
(vcib) and (te9). 

Theorem 3.8.3 (soundness): 

The inference rules of systems SI are sound with respect to the 

interpretation of judgments given in section 3.8. 
Proof 

By induction on the length of the derivation of the judgments. 

Environments 

(ENVi). Vacuously true. 
(ENV2). Vacuously true. 

(ENV3). By hypothesis, E\- A type and so Ap c l^for any p satisfying E. 

Moreover, E is well-formed by lemma 3.7.1, hence E,X<:A is also 

well-formed. 
(ENV4). Similar to (env3). 

Variables 

(VARi). If p satisfies E,X,E\ then by definition p(Z) e V. 

(VAR2). If h E,X<:A,E' env, then for any p satisfying E we have Ap c 1^ 

Thus any p satisfying E,X<:A,E' must yield p(X) e Ap e 'H 
(VAR3). Similar to (var2). 

(VAR4). If h E,x:A,E' env, then for any p satisfying E we have p(x) e Ap 
e I'. Thus any p satisfying E,x:A,E' must yield p(;c) e Ap e "^I 

General 

(Gi). If, for every p satisfying E, Ap=Bp c 'J/'then Ap c Bp. 
(G2). By transitivity of subset. 

(G3). If, for every p satisfying E, apcAp andAp e Bp then upeBp. 
(G4). By symmetry of equality. 
(G5). By transitivity of equality. 

(G6). If, for every p satisfying E, ap=bp e Ap then bp=ap e Ap. 
{G7). If, for every p satisfying E, ap=bp e Ap and Z7p=Cp e Ap 
then ap=Cp e Ap. 
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Formation 

(Fl). ^ C '^^ 

(F2). If, for every p satisfying E, Rp e and Ap e 1^ 

then 7?p[xAp] c 5^, c 1/ by Lemma 3.8.2. 
{F3). If i?p c 5^,, then i?p-x c 1^, by Lemma 3.8.2. 
(¥4). If i?p c 5'p[;c:Ap] e ^, then Ap c hence i?p(x) e 0^ by Lemma 3.8.2. 

Subtyping 

(51) . If, for every p satisfying E, Rp c ^-jc, then Rp is a set of finite 

functions re L ^g^l^ with x ^ dom{r). For each such r, and any 
a e Ap c 'J^, we have r[x=d\ e L ^g^l^. Thus i?p[x:Ap] e ^. 

(52) . If Rp c 5^,, then Rp-x e /?p e 

(53) . Suppose i?p e Sp e li^-x and Ap c 5p c 1^. Let re7?p[x:Ap]. 
This means ^seRp with r = 5[;c=fi!]. Since seSp and Ap e Bp, 
we have s\x=d\ e Sp[x.Bp]. Hence i?p[xAp] c Sp[x:Bp]. 

(54) . Suppose i?p e 5p e ^. If r'ei?p-x, then r' = r-x for some reRp. 

Since re^p, it follows that r' = 

(55) . Suppose 7?p e Sp[x:Ap] e ^, then for any reRp, re5p[x:Ap] = {5[x=a] I 
seSp, aeAp}; so that r{x)eAp. Hence 7?p(x:) = {r(x) I reRp} cAp. 

(56) . Suppose Rp c 5p[x:Ap] c i^, then for any reRp, reSp[x:A], so that 

r=s[x=a] for some seSp and aeAp. We haYea=r(x)eRp(x), and 
s=r-xeRp-x, hence r=(r-x)[j::=r(j^)]e(i?p-x)[x:i?p(x)]. It follows that 
RpURp-x)[x:Rp(x)]. 

Introduction 

ai). 0 e ^ e 1^ 

(12) . If, for every p satisfying E, the empty function 0 e i?p ^ ^, 

then 0 = 0 -x^..x„ e i?p-j e 

(13) . If rpeRp withx ^ dom{rp) andopfeAp, then rp[x=ap] is well-defined, 

by Lemma 3.8.1, and belongs to i?p[xAp] c by Lemma 3.8.2. 

Elimination 

(El). If, for every p satisfying E, rpeRp c ^, then x i dom{rp-x). 

Hence rp-x e Rp-x c ^, by Lemma 3.8.2. 
(E2). If rpei?p[A::Ap] e ^, then Ap e 1^, and rp is a record with rp(A;)eAp. 

Type congruence 
(TCI). c "P. 

(TC2). For every p satisfying E, Xp =Xp c V. 
(TC3). Suppose Rp=Sp, Sp e ^-x, and Ap=Bp c 

Then /?p[x:Ap] = 5p[xfip] e ^ c 1/. 
(TC4). Suppose Rp=Sp e then i^p-x^S'p-x c e '^I 
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(TC5). Suppose Rp=Sp c rp[x:Ap] c ^. 

Then both Rp and Sp are sets of functions r with x ^ dom(r). 
Hence i?p(jc) = {K^) I rei?p} = {r(x) I re5p} = Sp(x) e 

Type equivalence 

(TEi). Suppose, for every p satisfying E, Rp c (^-x)-};, Ap^p ^ "J^, 
and ^c,}" e L. For each re^p, x,y i. domif). Then, 
i?p[x:Ap][y:5p] = 

{s\y=b\ 1 5'e{r[jc=a] I ^i?p, aeAp}, Z7e5p} = 

{r[x=a][};=&] I rei?p/?eAp,Z7e5p} = {r[3;=&][j:^a] I re/?p,Z7e5p,aeAp}= 
{s[x=a] I se{r\y=b\ I rei?p, Z7e5p}, aeAp} = 
/?p[y:5p][xAp]e^e1/ 
{TE2). If 7?p c then i?p is a set of r with ;c i. domif). Hence ^p-;c = ^p. 
(TE3). If i?p c then (Rp-x)-y = (Rp-y)-x. 
(TE4). Suppose Rp c Sp\y:Bp] c ^ andjc^^^:};. 
For each reRp, y ^ dom{r). Then, 
{Rp-x)iy) = 

{s(y) I se{r-x I rei?p}} = {(r-x)(y) I rei?p} = {rO;) I reRp} = 

Rp(y) £ 1^. 
(TE5). Suppose i?p c Hi^-x and Ap c 1^! 

Theni?p[xAp] = {r[x=a] I ^i?p,aeAp}. 
So (i?p[x:Ap])-x= {r I reRp] =Rp. 
(TE6). Suppose Rp e ^-x, Ap e "J^, and js^. Then, 
(Rp[x:Ap])-y = 

{(r{x=a])-y I rei?p, oeAp} = {(r-}')[x=a] I reRp,aeAp} = 
(Rp-y)[x-Ap] ^ll^V 
(TE7). Suppose Rp c %^-x and Ap e 1/! 

Then i?p[x::Ap] = {r[j::=a] I reRp,aeAp}. 
Hence {Rp{x:Ap\){x) = {(r[x=a])(x) I reRp,aeAp] = ApC 1^ 
(TE8). Suppose Rp c Sp\y:Bp]-x e ^, Ap c 1^, and x?^3^. Then, 

(Rp[x:Ap])(y) = {(rix^a])(y) I re^p,fleAp} = {r(y) I ^i?p} =^p(y) e 'J^ 

Value congruence 
(TCI). ^6=0 c ^ 

(TC2). If, for every p satisfying E, p(x) e Ap c 1/", then p(x)=p(x) e Ap. 
(TC3). Suppose ^p=5p e ^p £ and ap=bp e Ap e l^! 

Then x ^ dom(rp)udom(sp). Hence rp[x=ap] = Sp[x^bp] e i?p[x:Ap] ^ ^, 

by case (i3). 

(TC4). Suppose rp=5p e i?p e ^. Then rp-x=Sp-x e i?p-x e ^, by case (ei). 
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(TC5). Suppose rp=sp e i?p c i'pCxiAp] e ^. 

Then Rp c (Rp-x)[x:Rp(x)] (by case (S6)), and rp^sp e (Rp-x)[x:Rp(xy\. 
Hence, by case (E2), rp(x)=sp(x) e Rp(x) e 1^. 

Value equivalence 

(VEi). Suppose, for every p satisfying E, rpeRp c ^-x-y, apCAp e 1^, 
bpeBp e and jk^. Then, dom(rp), and 
'"p[-^«p]tv=^p] = /ptv^^plL^^p] e Rp[x:Ap]\y:Bp] c i^. 

(VE2). 0 -X = 0 e ^. 

(VE3). Suppose rpei?p e ^-x. Since x ^ dom(rp), rp-x = rp. 
(VE4). Suppose rpeRp e ^. {rp-x)-y = {rp-y)-x e (Rp-x)-y e 3^. 
(VE5). Suppose rpeRp[x:Ap] c 3^ andx^^}'. 

Then x e dom(rp) and rp-y.x = rp.x e ApQ 'P'. 
(VE6). Suppose rpeRp e i^-x and apeAp c 1/1 

Then x ^ dom(rp) and rp[x=ap]-x = rp. 
(VE7). Suppose rpei?p e ^-x, apeAp e l^andxT^y. 

Then x ^ dom(rp) and (rp[x=ap])-y = (rp-y)[x^p] e (i?p[x:Ap])-3; e 3^. 
(VE8). Suppose rpe/?p e ^-x, and apeAp c l^! 

Then x ^ dom(rp) and (rp[x=ap])(x) = ap. 
(VE9). Suppose rpei?p[y:5p]-x e ^, apeAp c 'U andx^y. 

Then 5p c x dom(rp), y e dom(rp), and (rp[x=ap])(y) - rp(y) e Bp. 
(VEio). Suppose rpei?p c 5'p[x:Ap] e ^. 

Then rpe5p[x:Ap], so that rp=5'[x=a] for some se^p and aeAp. 

We have a=rp(x)e7?p(x), and j=rp-xei?p-x, hence rp=(rp-x)[x=rp(x)], 

which is well-formed (is a member of (Rp-x)[x:Rp(x)]). 

□ 

A construction giving R = <lR\x\x:R.xl) 

System S2 is system SI of Theorem 3.8.3 plus the rule (te9). 

Theorem 3.9.7 ( soundness): 

The inference rules of system S2 are sound with respect to the 

interpretation of judgments given in section 3.9. 
Proof 

The proof follows the general pattern of Theorem 3.8.3. The main new 
properties that are needed are proved as lemmas in section 3.9. 
In particular, (te9) follows from Lemma 3.9.6. The formation rules 
come from Lemmas 3.9.2, 3.9.3, 3.9.4, and 3.9.5. 
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An extensional model construction 

System S3 is system SI of Theorem 3.8.3 plus the rules (te9) and (vcib). 

Theorem 3.10.4 (soundness): 

The inference rules of system S3 are sound for the PER model 
construction given in section 3.10. 

Proof 

The proof follows the general pattern of Theorem 3.8.3, using the lemmas 
proved in section 3.10 

□ 
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